JavaScript as a language is changing every year now. Starting with the major changes brought into the language in 2015 with ES6 or ES2015, the language design team has been putting efforts to add new features to the language every year. The TC39 team proposes or reviews the features submitted based on the usage of JavaScript across different platforms and these features are designed to make the language more relevant. Some of these features add new syntax or improve the existing features, and some of them add new APIs.

Any new features to JavaScript must go through a process with the TC39 team. The proposals made to the TC39 team go through 4 stages of evaluations and when a proposal reaches stage 4, it is going to make it to the language specifications. The proposals at different stages can be found in the proposals repository. The proposals that reach stage 4 and are considered to be included in the coming version of the language can be found in the finished proposals.

The features included in ECMAScript 2022 add new features to the classes, allow modules to be asynchronous, improve to regular expressions, make custom errors more meaningful and add new capabilities to objects and arrays. Let’s dive in and explore these features now.

The list of features fir ES 2022 can be found in the list of finished proposals. Let’s look into these features. The table in the link also contains the list of features that could be included in ES 2023, we will look at those features in another article in the future.

JavaScript adds the method hasOwnProperty to all the objects inherited from Object, that can be used to check if the object contains a property. We can perform the following to check if an object has a property:

The downside of using hasOwnProperty is, it doesn’t work the way it is supposed to in certain cases. It is possible to create a custom property or a method in the object named as hasOwnProperty, as shown here:

In such cases the method can be used directly from Object.prototype to get the desired behavior, as shown below:

The proposal adds the method hasOwn to the Object that provides the same behavior. The method can be accessed directly from Object without the need of navigating to prototype and accessing it. Following are some examples using this method:

As shown in the case of obj3 in the above snippet, Object.hasOwn considers only direct properties and it doesn’t consider the inherited properties.

Today JavaScript doesn’t provide a way to apply negative indices on arrays, strings or collections. To find an element at a relative position from the end of an array, one needs to get the length and subtract the position to get the element, as shown below:

It is not possible to apply negative indices to the array accessor, as the syntax is not specific to arrays and strings. The accessor can be used with objects to get the value of a property. For example, we can do the following with objects:

The .at() proposal is to add a new method on iterable types to allow the negative indices. To get the second last item from the array shown in the snippet above, we can do it as follows:

Disclaimer: The method .at() is not yet available in any of the JavaScript platforms. The polyfill mentioned in the proposal of this feature can be used to play with it before it gets released.

This proposal introduces a new regexp flag that can be added at the end of a regular expression. It adds additional information in the result obtained after executing the expression on a string.

The new flag, d stands for index and it adds information related to indices of the full substring matched in the bigger string and the indices of the individual segments. Let’s look at an example to understand this, consider the following snippet:

The output of this snippet is shown in the following image:

As we see, the indices property of the matches object has a list of pairs of indices and groups. The groups property is null here as the regexp didn’t define any groups.

The first entry in the array of indices indicates the start and end indices of the full substring in which the matches were found. The subsequent entries have the indices of the individual match. As the text sample matches the expression fully, the entries have the same values.

Let’s modify the expression and see how it behaves. The following snippet modifies the expression to contain multiple matches:

The following image shows the output of this snippet:

The expression  has two parts. So the indices have multiple entries now.

If the regex contains groups, the indices.groups property would be set to the indices of each group. Let’s consider the following snippet:

The following image shows the output of this snippet:

Now the groups property in both matches and indices is set and we are able to see the values of substrings matched in the matches object. We also see indices of each group in the groups property of the indices object.

Similarly, the response of String.prototype.match and String.prototype.matchAll will have the additional indices information if the flag d is used with the regular expression passed to these methods.

This proposal is to support the use of the await keyword at the top level in an ES module. This makes the module using the await keyword a big async function and makes the importing modules to wait till the operation is completed. Node.js developers would have used this feature before others, as the proposal has been in review since 2014 and it was implemented in Node.js v13.8 about a year ago.

Today, we don’t have a direct way of exporting a value from a module which we get in response to an API call or from any other asynchronous source. There are multiple work-arounds to achieve this today. Following are two of the approaches I can think of now:

Top-level await solves these issues and provides a reliable and predictable way to import an asynchronous module. Let’s see an example for using top level await. The following snippets show the contents of two of the files in a simple Node.js application:

As we see here, the file server-request.ts makes a request to the GitHub REST API and it uses the await keyword at the top level. The client.ts file imports the server-request module and it prints the imported value on the console.

This code has to be executed on Node.js version 13 or above. It also requires the type property in the file package.json to be set to module, as shown below:

If you are using a Node.js version older than 14.8.0, you need to use the –harmony-top-level-await flag with the node command. With version 14.8 and above the flag is not required anymore. The following snippet shows the command with the flag:

Disclaimer: Top level await cannot be used on the browsers yet

The classes in current JavaScript don’t offer a way to make the fields or methods private. So it is difficult to hide the information that should not get accessed outside the class. This proposal adds the support for private fields and methods in the JavaScript classes. A point to remember is, constructors cannot be made private yet in JavaScript, they need to be public.

The proposal also adds the capability to declare the class fields before using them and without assigning any values to them. This feature makes the classes more documented for the developers working in the team, as one need not go looking for all the “this.” references in the class body to find all the members of the class.

A private field or method has to be prefixed with the pound (#) symbol. Any member of the class defined using the pound symbol is not accessible outside the class, it can be accessed only inside the class. The following example shows how to use the class fields and private members:

The following list describes the usage of fields and private variables in the above class:

Note: While field declaration makes the code more readable, it could lead to clutter if private and public variables are jumbled together in one set of declarations. It is good to keep the declarations of private and public members separated.

This proposal adds the support for static public fields, static private methods and static private fields to the class. The static members are specific to the class and not to the instances. They are created when the class gets referenced for the first time and they are created only once in the lifetime of the application.

The following snippet shows a class using the static features of the class:

The following listing describes the features used in snippet:

Any attempt to access the private static members results in an error similar to the error we get on accessing the private instance fields.

The static blocks provide a way to initialize the static fields of the class. They get executed only once in the lifetime of the application and it happens when the class is referenced for the first time.

In the snippet, the static field #count is initialized during declaration. It works for this case to be initialized here, but there could be scenarios where the static field is dependent on some other factors and needs to be assigned with a computed value. A static block can be used to write the logic required to perform the computation and then assign the value.

Say, we want to add a restriction to the person object saying the date of birth of the person should be at least 30 years prior to the current year. For this we can create a static variable to hold the year and initialize it in a static block. The following snippet shows this example:

As the static block has access to all the private static and private instance fields, it can be used to perform even some complex logic that involves the usage of private fields. The example in the proposal of this feature shows how the static block can be used to initialize an object in the module.

While using the instance fields (private or public) of an object inside the static methods or in the instance methods of another object of the same class, we need to be careful and check if the field exists in the object. Otherwise it may lead to some exceptions.

To check if a property exists, we generally use if conditions or ternary operators. The following snippet shows if a property exists in the object using an if condition:

The downside of this approach is, the if condition fails even when the field #name exists in the object and is assigned with the falsy values. It doesn’t actually check for the existence, it rather checks the value of the field.

The in keyword can be used to check if a property exists in an object. This approach seems more reliable as it checks for the presence and doesn’t take value into the account to confirm the existence. The following snippet shows how it is used today with objects:

The proposal for ergonomic brand checks extends this capability of checking the existence of the private fields in a class using the in keyword. The above snippet can corrected using the in keyword and re-written as shown below:

The expression inside the if condition is now replaced using the in keyword. Now this expression means “does obj have the field #name?”. It evaluates to true even when the value of the field is set to null or undefined.

Error handling is a crucial part of an application. The errors are not used just to the handle abnormal scenarios in the code, but they are also used to provide documentation for the users. If the error thrown from a place in the code doesn’t have enough information the user will have a harder time in figuring out the reason behind it before finding a fix.

ES 2022 adds a property to the error objects to help the authors of the errors to provide additional information describing cause of the error. The custom errors created to rethrow a generated error can include the property cause to describe the reason behind the error. The following snippet shows an example of this property:

It is also possible to provide more structured data to the cause property. The structured data is useful when the error object needs to be processed by the code that uses the functionality containing the custom error. In my opinion, this feature is useful for the library authors, as it provides a way for them to add additional information about the error that can be programmatically read by the consuming code and the application can handle the error in a better way. Snippet below shows an example of this feature.

The features that are added in ES 2022 offer a lot of new capabilities with classes, make the modules asynchronous with top level await and other features make the language a better fit for bigger applications. I hope this article provides a good start to these features and excites you to look forward for the next release of the language.

This article has been editorially reviewed by Suprotim Agarwal.

C# and .NET have been around for a very long time, but their constant growth means there’s always more to learn.

We at DotNetCurry are very excited to announce The Absolutely Awesome Book on C# and .NET. This is a 500 pages concise technical eBook available in PDF, ePub (iPad), and Mobi (Kindle).

Organized around concepts, this Book aims to provide a concise, yet solid foundation in C# and .NET, covering C# 6.0, C# 7.0 and .NET Core, with chapters on the latest .NET Core 3.0, .NET Standard and C# 8.0 (final release) too. Use these concepts to deepen your existing knowledge of C# and .NET, to have a solid grasp of the latest in C# and .NET OR to crack your next .NET Interview.

Click here to Explore the Table of Contents or Download Sample Chapters!